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Analyzing an Extended Finite State Machine System Model 

Background of the Invention 
System testing contributes significantly to system 
5 development and maintenance costs. TestMaster© software 
sold by Teradyne® Software and System Test, Inc. of Nashua, 
NH can reduce testing costs while increasing testing 
quality . 

Referring to FIG. 1, TestMaster® software 100 
io enables a designer to create 102 an extended finite state 

machine model of a system. An extended finite state machine 
- is represented by a directed graph that includes states 

interconnected by transitions. The software 100 provides a 
graphical user interface that enables the designer to "draw" 
15 the model by defining the states and connecting them 

together with directional lines that represent transitions. 

The model is independent of the system being modeled and 
can be created before or after the system is developed. 
After the designer creates 102 the model, the 
20 software 100 detects 104 paths through the model states and 
transitions and generates 106 testing programs corresponding 
to each of the detected paths. Execution of the generated 
testing programs can identify system design flaws and 
highlight differences between the model created and the 
25 actual behavior of the underlying system. 

Referring to FIG. 2, an extended finite state 
machine model 108 of a system includes states 110-116 
interconnected by transitions 118-124. For example, as 
shown, a model 108 includes states 110-116 and transitions 



WO 00/072145 PCT/US00/14248 



118-124 representing a bank machine system that dispenses 
cash to customers entering an authorized PIN (Personal 
Identification Number) . 

The TestMaster® system automatically detects 
5 different paths through the model 108. For example, as 
shown in FIG. 3, a path through the model can include model 
elements A - Tab - B - T BC - C - T CD - D . This path 
corresponds to a customer correctly entering an authorized 
PIN and successfully withdrawing cash. As shown in FIG. 4, 
10 a different path through the model can include model 

elements A - Tab - B - T B d - D. This model path corresponds 
to a customer who fails to correctly enter an authorized 
PIN. 

TestMaster® offers many different procedures for 
is detecting paths through a model. For example, a user can 
select from comprehensive, transition-based, N-switch, and 
quick-cover path detection. Comprehensive path detection 
outputs a test for every possible path through the model . 
Transition based path detection outputs tests such that each 
20 transition is included in at least one test. N-switch path 
detection outputs tests such. that each unique sequence of 
N+l transitions are included in at least one test. 
Comprehensive, transition, and N-switch path detection are 
currently implemented using a depth- first search. In 
25 contrast, quick-cover uses a "top-down" search and can 
output tests such that no transition is used more than a 
specified number of times. U.S. Patent Serial No. 
08/658,344 entitled "Method and Apparatus for Adaptive 
Coverage in Test Generation" describes implementations of 
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programs for detecting extended finite state machine paths. 

Referring again to FIG. 2, in addition to 
transitions and states, a model can incorporate variables 
and expressions that further define the model's behavior. 
5 TestMaster® can evaluate the expressions to assign variable 
values (e.g., y = mx + b) or to determine whether an 
expression is TRUE or FALSE (e.g., A AND (B OR C) ) . The 
expressions can include operators, variables, and other 
elements such as the names of states, transitions, and/or 

10 sub-models. When a named state, transition, or sub-model is 
in included in an expression, the model element evaluates to 
TRUE when included in the path currently being detected. 
For example, in FIG. 2, an expression of "(A B) " would 
evaluate to TRUE for path portion "A - Tab - B". As 

15 shown, expressions can use a PFL (Path Flow Language) syntax 
that resembles the C programming language. PFL and 
functions that can be called from PFL are described in The 
TestMaster® Reference Guide published by Teradyne®. 

A model designer can associate the expressions with 

20 model elements to further define model behavior. For 
example, a designer can associate predicates and/or 
constraints with different states, transitions, and/or sub- 
models. Both predicates and constraints are evaluated 
during path detection and determine which transitions can be 

25 included in a path. 

When path detection instructions encounter a model 
element having an associated predicate, the predicate 
expression is evaluated. If the predicate evaluates to 
TRUE, the model element associated with the predicate can be 
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used in the path. For example, as shown in FIG. 2, 
transition T B d 124 has an associated predicate 126 
("! OKPin") that determines when a path can include the 
transition. As shown, the predicate 126 is a boolean 
5 expression that permits inclusion of the transition 124 in a 
path being detected when the boolean variable OKPin is FALSE 
and the path being detected has reached state B. 

Similarly, when path detection instructions 
encounter a model element having an associated constraint, 
10 the constraint expression is evaluated. If the constraint 
evaluates to FALSE, the model element associated with the 
constraint cannot be used in the path being detected. For 
example, as shown in FIG. 2, a transition 123 can connect a 
state 114 to itself. To prevent a path from including a 
is large or possibly infinite number of the same transition in 
a single path, a designer can specify a constraint 
expression 125 that limits use of a transition in a path. 
The "Iterate (3) » expression associated with the transition 
123 limits a path through the model to including transition 
20 123 three times. Thus, if evaluated at state C after 
looping around transition T cc three times, the constraint 
would evaluate to FALSE and prevent further use of the 
transition in the current path. The constraint acts as a 
filter, eliminating generation of unwanted testing programs. 

Referring to FIG. 5, a model can also include one or 
more sub-models. For example, the box labeled "EnterPIN" in 
FIG. 2 may be a sub-model 112 that includes additional 
states 128-136, transitions 138-150, and expressions. As 
shown, the sub-model 112 sets 150 the model variable OKPin 



25 



SDOCIO <WO 00721 45A1 IA> 



WO 00/072145 



PCT/US00/14248 



to TRUE when the customer PIN equals 1 148; otherwise, the 
sub-model sets the model variable OKPin to FALSE 146. 

Sub-models encourage modular system design and 
increase comprehension of a model's design. Referring to 
5 FIG. 6, when the software 100 detects different paths 
through the system, the sub-model is essentially replaced 
with the states and transitions included in the sub-model. 

Referring again to FIG. 5, a designer can define 
more than one transition 138-142 between states 128, 130. 

10 The designer can also associate expressions (e.g., PIN = 1) 
with each transition 138-142, for example, to set model 
variables to different values. For example, as shown, a 
designer has defined three transitions between the "Entry" 
128 and "PINEntry" 130 states that each set a PIN variable 

15 to different value. Defining multiple transitions between 
states increases the number of paths through a model. For 
example, paths through the sub-model 112 can include I - 
Tutu - J - Tjk - K - Tkm - M, I - Tij( 2 ) - J - Tjl - L -Tlm - M, 
and I - Tijo) - J - Tjl - L - Tlm - M. The use of multiple 

20 transitions enables testing of different conditions within 
the same model . 

Summary of the Invention 
In general, in one aspect, a method of using a 
25 computer to analyze an extended finite state machine model 
of a system includes receiving at least one requirement 
expression, determining at least one path of states and 
transitions through the model, evaluating at least one of 
the requirement expressions based on at least one of the 
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determined paths through the model to determine whether the 
path satisfies the requirement expression, and generating a 
report based on the evaluating. 

Embodiments may include one or more of the 
5 following. The report may include a report of paths 

satisfying at least one requirement. The report may include 
a report of requirements satisfied by a path. The 
requirement expression may be a boolean expression. The 
requirement expression may include a variable, an operator, 
10 a state, a transition, a sub-model, a table-model, and/or 
another requirement expression. The method may generate 
testing programs only for paths satisfying a specified 
requirement or set of requirements. 

In general, in another aspect, a method of using a 
is computer to analyze an extended finite state machine model 
of a system includes receiving a requirement expression, 
determining at least one path of states and transitions 
through the model, evaluating at least one of the 
requirement expressions based on at least one of the 
20 determined paths through the model to determine whether the 
path satisfies the requirement expression, and including the 
requirement expression as an element in a different 
expression, the evaluation of the requirement expression in 
the different expression depending on the determination of 
25 whether the path satisfies the requirement expression. 

In general, in another aspect, a method of using a 
computer to analyze an extended finite state machine model 
of a system includes receiving at least one assertion 
expression, evaluating the assertion expression based on a 
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path being determined through the model, and if the 
evaluation indicates the path being determined fails to 
satisfy the assertion expression, indicating the failure. 

Embodiments may include one or more of the following 
5 features. The method may further include halting model path 
determination. The assertion expression may be a boolean 
expression. The assertion expression may include a 
variable, an operator, a state, a transition, a sub-model, a 
table-model, and/or a requirement. The method may further 
10 include initiating a debugger if the evaluation indicates 
the path being determined fails to satisfy the assertion 
expression. The method may include receiving user input 
specifying when the assertion expression is evaluated. 
Specifying when the assertion expression is evaluated may be 
is performed by specifying a model element. 

The method may include automatically evaluating the 
assertion expression after a complete path through the model 
has been determined and/or automatically evaluating the 
assertion expression as model elements are added to a path 
20 being determined. 

In general, in another aspect, a computer program 
product, disposed on a computer readable medium, for 
analyzing an extended finite state machine model of a 
system, includes instructions for causing a processor to 
25 receive at least one requirement expression, determine at 
least one path of states and transitions through the model, 
evaluate at least one of the requirement expressions based 
on at least one of the determined paths through the model to 
determine whether the path satisfies the requirement 
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expression, and generate a report based on the evaluating. 

In general, in another aspect, a computer program 
product, disposed on a computer readable medium, for 
analyzing an extended finite state machine model of a system 
5 includes instructions for causing a processor to receive a 
requirement expression, determine at least one path of 
states and transitions through the model, evaluate at least 
one of the requirement expressions based on at least one of 
the determined paths through the model to determine whether 
10 the path satisfies the requirement expression, and include 
the requirement expression as an element in a different 
expression, the evaluation of the requirement expression in 
the different expression depending on the determination of 
whether the path satisfies the requirement expression, 
is In general, in another aspect, a computer program 

product, disposed on a computer readable medium, for 
analyzing an extended finite state machine model of a system 
includes instructions for causing a processor to receive at 
least one assertion expression, evaluate the assertion 
20 expression based on a path being determined through the 
model, and if the evaluation indicates the path being 
determined fails to satisfy the assertion expression, 
indicate the failure. 

25 Brief Description of the Drawings 

These and other features of the invention will 
become more readily apparent from the following detailed 
description when read together with the accompanying 
drawings, in which: 
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FIG. 1 is a flowchart of a process for using an 
extended finite state machine model to generate tests for a 
system according to the PRIOR ART; 

FIG. 2 is a diagram of an extended finite state 
5 machine model according to the PRIOR ART; 

FIGS. 3 and 4 are diagrams of paths through the 
extended finite state machine model of FIG. 2 according to 
the PRIOR ART; 

FIG. 5 is a diagram of a sub-model according to the 
10 PRIOR ART; . 

FIG. 6 is a diagram of the extended finite state 
machine model that includes the states and transitions of 
the sub-model of FIG. 5 according to the PRIOR ART; 

FIG. 7 is a flowchart of a process for determining 
15 whether a system model satisfies system requirements; 

FIG. 8 is a screenshot of a table of system 
requirements used by the process of FIG. 7; 

FIG. 9 is a screenshot of a requirements report 
produced by the process of FIG. 7; 
20 FIG. 10 is a flowchart of a process for determining 

whether a system model satisfies specified assertions; 

FIG. 11 is a diagram of an extended finite state 
machine model that includes a table model element; 

FIG. 12 is a diagram of a table having rows 
25 incorporated into the model; 

FIG. 13 is a flowchart of a process for selecting a 
transition based on likelihood values associated with the 
transitions ; 

FIG. 14 is a flowchart of a process for importing 
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data and other information into an extended finite state 
machine model ; 

FIG. 15 is a listing of a comma separated value file 
having values that can be imported into an extended finite 
5 state machine table model element; 

FIG. 16 is a flowchart of a process for detecting 
paths through a model that conform to a user specified mix 
of paths ; and 

FIG. 17 is a diagram of a finite state machine model 
10 that includes model elements having target mix values. 

Description of the Preferred Embodiments 
Introduction 

15 The inventors have invented different mechanisms 

that enable testers, developers, and others to detect design 
and implementation flaws in a system. These mechanisms can 
be included in TestMasterd) or other software or hardware 
systems . 

20 , 

Requirements and Assertions: 

Referring to FIG. 7, prose descriptions of system 
requirements often appear in functional and design 
specifications or are included in requirement documents 
25 produced by a customer. Requirements can also be gleaned 
from customers, bug- lists, etc. As shown in FIG. 7, a 
process 200 enables users to specify 202 requirements as an 
expression of elements (e.g., variables, sub-models, states, 
and transitions) . For each path 204 through a model, the 
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process 200 evaluates 206 all requirement expressions to 
determine which requirements are satisfied. 

For example, referring again to FIG. 2, the bank 
machine system functional specification may describe a 
5 requirement that no withdrawals should occur if a customer's 
PIN is not authorized. A user can ensure compliance with 
this requirement by defining a boolean expression of "NOT 
(withdrawal AND (NOT OKPin) ) 11 . After each path is detected 
through the model, the requirement expressions defined for 

10 the model are evaluated. The path satisfies any requirement 
expression that evaluates to TRUE. 

Referring to FIG. 8, a user can specify and view 
requirement expressions via a graphical user interface. The 
interface shown enables a user to specify each system 

is requirement as a row in a table 222. The table 222 includes 
columns for a requirement ID 208 and version number 210 for 
each requirement. This enables a user to quickly correlate 
requirements with their descriptions in written documents 
and specify which collections of requirements should be used 

20 during path detection (e.g., only version 2 requirements 

need be satisfied) . The requirement ID 208 can also be used 
as elements in other requirement expressions. 

The table also includes columns for a prose 
description 212 of each requirement and the boolean 

25 requirement expression 216. The table can also include a 
column 214 for specifying a system feature involved in the 
requirement . A feature may have more than one associated 
requirement. Additionally, a table column may permit a user 
to name the row for inclusion in other expressions. 
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Further, a table can include a "source" column 218 for 
Hyperlinks (e.g., Universal Resource Locators) which link to 
external documents describing a requirement . 

The information included in the table 222 may be 
5 entered manually or imported, for example, from a database, 
spreadsheet, or a CSV (comma separated value) file. 
Similarly, the table 222 information may also be exported. 
Additionally, different requirements may be enabled or 
disabled by a user. 
10 Referring to FIG. 9, the process can generate a 

report 224 that describes tests that can be run to test the 
specified requirements. As shown, the report 224 may be a 
table that includes a row for each test generated and an 
indication of the different requirements satisfied by the 
X5 test. For example, row 231 for test path 3 satisfies 
requirements 1.0.1 and l.l. 

The report 224 can also summarize test results, for 
example, by displaying the number of tests satisfying each 
requirement 226 or displaying the number of requirements a 
20 particular path satisfied 232. The report enables a user to 
understand the completeness of a set of tests, to understand 
how many of the requirements have been included in the 
model, to perform optimization, and to detect tests that do 
not satisfy defined requirements. Based on the report the 
25 user can see which paths satisfied the requirement and use 
the testing programs generated for these paths to test the 
system being modeled. 

The requirements feature described above can also 
limit (i.e., "filter") the test scripts generated. For 
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example, a user can specify that test scripts should only be 
generated for paths" satisfying a particular requirement. 
Thus, only testing programs directed to testing particular 
features are generated. Additionally requirement 
5 information can be output to a CSV (comma separated value) 
file, spreadsheet, or database. 

Referring to FIG. 10, similar to requirements, 
assertions enable a user to specify an expression for 
evaluation. However, while a path through a perfectly 

10 designed model may not satisfy any requirement expressions, 
assertions represent expressions that should always be 
satisfied (e.g., TRUE) when evaluated. Failure to satisfy 
an assertion can represent significant model flaws needing 
immediate attention (e.g., when an abnormal or unexpected 

15 condition occurs) . 

A process 24 0 for determining whether a model 
complies with a set of assertions includes receiving 242 
assertion expressions. A user can specify that an assertion 
expression be evaluated at different points in the model, 

20 for example, before or after entering a particular state, 

transition, or sub-model. In another embodiment, a designer 
can specify that an assertion expression should be 
automatically evaluated before and/or after entering every 
sub-model element. Additionally, a designer can specify 

25 that an assertion expression should be automatically 

evaluated after each path through the model is detected. 

When the process 240 determines 246 a path violates 
an assertion (i.e., the boolean assertion expression 
evaluates to FALSE) , the process 24 0 can immediately alert 
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248 the user of the particular path and other model 
information that caused the assertion violation. For 
example, the process 24 0 can call a model debugger that 
enables a user to view model information such as the value 
5 of different variables, the assertion violated, and model 
elements in the path that violated an assertion. This 
enables a user to examine the model context that caused the 
assertion to fail. The process 24 0 can further provide an 
error message and/or provide a display that highlights the 
10 path the caused the violation. 

Transition Tables : 

Referring to FIG. 11, a graphical user interface 
provides a table 14 3 model element the user can include in a 
is model. The table 143 can specify multiple sets of data to 
be included in the generated test. 

Referring to FIG. 12, each row can include one or 
more variable value assignments, for example, each row can 
include a different value for the PIN model variable 250 and 
20 a name of the customer assigned that PIN (not shown) . Each 
row can further include predicate 2 54 and/or constraint 
expressions 256. The path detection instructions can select 
one or more of the rows for each path. Thus, the table 14 3 
provides a convenient mechanism for viewing and defining 
25 large sets of data. 

In another embodiment, the table also includes 
columns for specifying a source state and a destination 
state for each transition row (not shown) . This enables an 
entire model to be displayed as one or more tables of rows. 

- 14 - 
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The tables can be used to automatically generate a 
graphical display of a model. Similarly, a graphical model 
could be used to generate corresponding tables . The 
equivalence of the model and the table enable a user to 
5 easily "flip" between the different model representations. 

Additionally, the table may offer a column for a 
name of the row (not shown) . The named model element can 
then be included in other expressions. 

Each row of the table 143 can also include a 

10 likelihood value 252. The likelihood values can be used to 
select a row from the table during path detection. 
Referring also to FIG. 13, a process 258 for selecting a row 
based on likelihood values includes determining currently 
eligible rows 260, normalizing the likelihood values of the 

is eligible transitions 262 to produce a probability for each 
eligible transition, and selecting a transition based on the 
produced probabilities. 

For example, assume the TEST model variable is set 
to "1" in FIG. 12. Under this assumption, PINs 001, 002, 

20 003, and 004 represent eligible transitions because these 
transitions satisfy their associated predicate and/or 
constraint expression ( s ) . As shown, the likelihood values 
in a table need not add to 1 or 10 0. For example, adding 
the likelihood values of the eligible rows (PINs 001, 002, 

25 003, and 004) yields a total of 160. A row (e.g, 

representing a transition) can be selected by using the 
total likelihood value and the individual likelihood values 
of the eligible rows to dynamically create selection ranges 
for each row. For example, a sample set of ranges may be: 
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PIN=001 



0.000 



0.062 (e.g., 10/160) 



5 



PIN=004 



PIN=003 



PIN=002 



0.751 



0 .189 



0 . 063 



0.188 (e.g., 0.062 + 20/160) 
0.750 (e.g., 0.188 + 90/160) 
0.999 (e.g., 0.750 + 40/160) 



Thereafter, a row can be selected by generating a random 
number between 0 and 1 and selecting the transition having a 
range covering the generated number. For example, a random 

10 number of 0.232 would result in the selection of the 
transition setting the PIN variable to "003". Use of 
probabilities enables a model to be tested using data that 
reflects actual usage. Additionally, the use of 
probabilities enables a small set of rows to represent a 

15 large set of data. Further, normalizing likelihood values 
to produce probabilities enables the path detection 
instructions to process probabilities with different 
combinations of eligible rows. 



20 features describe above. For example, probabilities and/or 
likelihood values can be assigned to transitions with or 
without the use of table model elements. Additionally, 
though the determination of eligible transitions and 
normalizing their respective likelihood values provides a 

25 designer with flexibility, these actions are not required to 
take advantage of the benefits of including probabilities in 
the model. 

Importing Data into the Model: 



Other embodiments can include variations of the 
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The rows in the table and other model information 
can be hand entered by a user. Alternatively, a user can 
import the data from an external source. Referring to FIG. 
14, a process 250 enables users to import data into a model 
5 by specifying 252 an external information source for 

importing 254 into the model. For example, referring to 
FIG. 15, for, a user can specify a file name of a CSV (Comma 
Separated Value) file. The first line 266 of the CSV file 
defines table schema information such as the table variables 

10 and their corresponding data types. For example, as shown 
the variable named PIN has been type-cast as a number 268. 
Subsequent information in the CSV is paired with the 
variables defined in the first line 26 6. For example, the 
number 001 is paired with the variable PIN while the string 

15 "FirstPIN" is paired with the string variable named 
Otherlnf ormation . 

A database or spreadsheet could also be used as a 
source of external data. For example, a user could specify 
a relational database view or table. In response, 

20 instructions can automatically access the database to obtain 
schema information for the table. For example, an SQL 
(Structured Query Language) select command can be used to 
determine the variables and data included in a particular 
table or view and output this information to a CSV file. 

25 For interfacing with different types of data sources, the 
instructions may support ODBC (Open Database Connectivity) 
drivers . 

Importing data from an external source can relieve a 
user from having to define a large number of transitions 
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between states by hand. However, the importing capability 
is not limited to transitions. Additionally, the imported 
data can reflect actual testing conditions. For example, a 
log file produced by a system in actual use can provide a 
5 valuable source of data for the model . 

Specifying a Mix of Paths: 

Referring to FIG. 16, a process 300 enables a user 
to control the mix of paths outputted during path detection. 

10 The process 300 enables a user to specify 302 a desired mix 
of generated tests. For example, a user can specify a 
percentage (or ratio) of paths that include a particular 
model element or that satisfy a particular expression. 
During path detection, instructions track the current mix of 

15 paths (e.g., how many paths are in the mix and how many 

paths include the model element) and determine 3 06 whether a 
newly detected path brings the mix closer to the user 
specified percentage (s) . If so, the newly detected path is 
saved in the mix. Otherwise, the path is discarded. 

20 Many different procedures for determining whether a 

detected path brings the mix close to the user specified 
percentages could be used. For example, one procedure saves 
a detected path if the path satisfies any specified 
expression that is currently under-represented in the mix 

25 generated thus far. For example, referring to FIG. 17, a 
bank machine model 320 includes states 322-330 that 
represent different bank machine transactions. As shown, a 
user has specified that the mix of paths generated should 
include 40% 332 withdrawals 322 and 35% 334 checking-to- 
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savings 330 transfers. Assume that after nine paths, two 
paths have included withdrawals 332 (i.e., 22%) and three 
have included checking- to-savings 330 (i.e., 33%) 
transactions. Further assume a newly generated path 
5 included the model elements A - Tab - B - T B f - F. This path 
includes a withdrawal 332, but no checking- to- savings 33 0 
transactions. Since the running percentage of withdrawals 
332 is only 22% as compared to a target of 40%, the new path 
will be included in the mix. 

10 Other embodiments use different techniques for 

determining whether a path improves the mix of tests. For 
example, in the previous example, including the new path 
improved the percentage of withdrawals 332 from 22% to 33%, 
but would lower the percentage of checking- to-savings 330 

is transactions to 30%. Thus, saving the new path in the mix 
would bring the percentage of withdrawals 332 in the mix 
closer to the withdrawal target by 8% while bringing the 
percentage of checking- to-savings 330 by 3% away from its 
target. One embodiment totals the amount each current 

20 percentage is from its target percentage and compares this 
to the same total if the current path were saved in the mix. 

If the total would be reduced by inclusion of the path, the 
path is saved in the mix. Additionally, in some 
embodiments, a user can specify that some target percentages 

25 take priority over others. 

The specified targets need not add up to 100% as 
each test mix expression is independent of the other 
expressions. For example, as shown in FIG. 17, the targets 
only totalled 75%. This gives a user flexibility in using 
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the test mix feature. 

By specifying a mix of paths, a user can generate 
tests for model features of interest without defining 
additional expressions to control model behavior, 
s Additionally, the technique enables a user to produce tests 
relevant to areas of interest or that mimic behavior of 
interest . 

Other Embodiments: 

.0 The techniques described here are not limited to any 

particular hardware or software configuration; they may find 
applicability in any computing or processing environment. 
The techniques may be implemented in hardware or software, 
or a combination of the two. Preferably, the techniques are 

5 implemented in computer programs executing on programmable 
computers that each include a processor, a storage medium 
readable by the processor (including volatile and non- 
volatile memory and/or storage elements) , at least one input 
device, and one or more output devices. Program code is 

o applied to data entered using the input device to perform 
the functions described and to generate output information. 

The output information is applied to one or more output 
devices . 

Each program is preferably implemented in a high 
5 level procedural or object oriented programming language to 
communicate with a computer system. However, the programs 
can be implemented in assembly or machine language, if 
desired. In any case, the language may be a compiled or 
interpreted language . 
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Each such computer program is preferable stored on a 
storage medium or device (e.g. , CD-ROM, embedded ROM, hard 
disk or magnetic diskette) that is readable by a general or 
special purpose programmable computer for configuring and 
5 operating the computer when the storage medium or device is 
read by the computer to perform the procedures described in 
this document. The system may also be considered to be 
implemented as a computer-readable storage medium, 
configured with a computer program, where the storage medium 
10 so configured causes a computer to operate in a specific and 
predefined manner . 

Other embodiments are within the spirit and scope of 
the appended claims. 



- 21 - 



WO 00/072145 PCT7US00/14248 



What is claimed is: 

1 1 . A method of using a computer to analyze an 

2 extended finite state machine model of a system, the model 

3 having states interconnected by transitions, the method 

4 comprising: 

5 receiving at least one requirement expression; 

6 determining at least one path of states and 

7 transitions through the model; 

8 evaluating at least one of the requirement 

9 expressions based on at least one of the determined paths 
10 through the model to determine whether the path satisfies 
n the requirement expression; and 

12 generating a report based on the evaluating. 

1 2. The method of claim 1, wherein the report 

2 comprises a report of paths satisfying at least one 

3 requirement . 

1 3. The method of claim 1, wherein the report 

2 comprises a report of requirements satisfied by a path. 

1 4. The method of claim 1, wherein the requirement 

2 expression comprises a boolean expression. 

1 5. The method of claim 1, wherein the requirement 

2 expression comprises at least one of the following: a 

3 variable, an operator, a state, a transition, a sub-model, a 

4 table-model, and another requirement expression. 
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1 6. The method of claim 1, further comprising 

2 generating testing programs only for paths satisfying a 

3 specified requirement or set of requirements. 

1 7. A method of using a computer to analyze an 

2 extended finite state machine model of a system, the model 

3 having states interconnected by transitions, the method 

4 comprising: 

5 receiving a requirement expression; 

6 determining at least one path of states and 

7 transitions through the model ; 

8 evaluating at least one of the requirement 

9 expressions based on at least one of the determined paths 
io through the model to determine whether the path satisfies 
n the requirement expression; and 

12 including the requirement expression as an element 

13 in a different expression, the evaluation of the requirement 

14 expression in the different expression depending on the 

is determination of whether the path satisfies the requirement 

16 expression. 

1 8. A method of using a computer to analyze an 

2 extended finite state machine model of a system, the model 

3 having states interconnected by transitions, the method 

4 comprising: 

5 receiving at least one assertion expression; 

s evaluating the assertion expression based on a path 

7 being determined through the model; and 

8 if the evaluation indicates the path being 

9 determined fails to satisfy the assertion expression, 
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10 indicating the failure. 

1 9. The method of claim 8, further comprising 

2 halting model path determination. 

1 10. The method of claim 8, wherein the assertion 

2 expression comprises a boolean expression. 

1 11. The method of claim 8, wherein the assertion 

2 expression comprises at least one of the following: a 

3 variable, an operator, a state, a transition, a sub-model, a 

4 table -model, and a requirement. 

1 12. The method of claim 8, further comprising 

2 initiating a debugger if the evaluation indicates the path 

3 being determined fails to satisfy the assertion expression. 

1 13. The method of claim 8, further comprising 

2 receiving user input specifying when the assertion 

3 expression is evaluated. 

1 14. The method of claim 13, wherein specifying when 

2 the assertion expression is evaluated comprises specifying a 

3 model element . 

1 15. The method of claim 8 , further comprising 

2 automatically evaluating the assertion expression after a 

3 complete path through the model has been determined. 

i 16. The method of claim 8, further comprising 
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2 automatically evaluating the assertion expression as model 

3 elements are added to a path being determined. 

1 17 . A computer program product, disposed on a 

2 computer readable medium, for analyzing an extended finite 

3 . state machine model of a system, the model having states 

4 interconnected by transitions, the computer program product 

5 including instructions for causing a processor to: 

6 receive at least one requirement expression; 

7 determine at least one path of states and 

8 transitions through the model; 

9 evaluate at least one of the requirement expressions 

10 based on at least one of the determined paths through the 

11 model to determine whether the path satisfies the 

12 requirement expression; and 

13 generate a report based on the evaluating. 



18. A computer program product, disposed on a 
computer readable medium, for analyzing an extended finite 
state machine model of a system, the model having states 
interconnected by transitions, the computer program product 
including instructions for causing a processor to: 

receive a requirement expression; 

determine at least one path of states and 
transitions through the model; 

evaluate at least one of the requirement expressions 
based on at least one of the determined paths through the 
model to determine whether the path satisfies the 
requirement expression; and 

include the requirement expression as an element in 
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a different expression, the evaluation of the requirement 
expression in the different expression depending on the 
determination of whether the path satisfies the requirement 
expression . 

19. A computer program product, disposed on a 
computer readable medium, for analyzing an extended finite 
state machine model of a system, the model having states 
interconnected by transitions, the computer program product 
including instructions for causing a processor to: 

receive at least one assertion expression ; 

evaluate the assertion expression based on a path 
being determined through the model; and 

if the evaluation indicates the path being 
determined fails to satisfy the assertion expression, 
indicate the failure. 
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